Traditional Functional IC Test
Traditional functional Integrated Circuit (IC) testing exercises the Device Under Test (DUT) in its normal operational mode. That is, by applying values to the pins of the device and measuring the results, it uses the normal operation of the IC to put the internal device logic into states that allow particular faults to be detected.
There is wide variation in how tests are organized and applied to the device in traditional test. In general terms, to perform a test the DUT is clocked through multiple cycles, with a specified pattern of inputs applied and outputs measured at each cycle. A Test Program consists of a sequence of these tests. Tests do not overlap; however, there may be complex interdependencies between tests (one test relying on a previous test having placed the DUT in a particular state).
IC Test Systems today are designed to perform these sorts of tests. (By Test System, we mean the combination of a Tester, which exercises the DUT, and the accompanying hardware and software system that has access to and control of the Tester.) These testers employ an internal format to specify the Test Program. The details are specific to each Test System, but all represent the data in cyclized form, with Force values (input value applied to the DUT) and Expect values (output value expected from the DUT) for each cycle.
Because of the differences in internal formats and Tester capabilities, each test program is specific to a particular Test System. Test Programs are either coded with knowledge of the Test System requirements, or are modified to conform to those requirements when translated from an interchange format into the internal format.
When the Test System applies the Test Program to the device under test, device faults are detected as mismatches between Expect value and the values actually produced by the DUT. The Test System reports these mismatches in terms of the failing cycle number and pin name.
The Limits of Functional Test, Structural Test Alternative
As IC complexity has increased, to current devices with 10-100 million gates, they have become increasingly difficult to test effectively or efficiently using traditional functional test. Using normal device operations, it can be a complex task to establish the logic state required to detect a particular fault, and it becomes increasingly difficult to determine the fault coverage of a test program. Moreover, the largely manual effort of creating the test program becomes prohibitively expensive.
Complex ICs are typically built out of components in a hierarchical structure, and many of these components are reused in multiple ICs. There is a benefit to being able to develop tests for these components that can also be reused, and this is typically not feasible with traditional functional test. There is also a benefit, when faults are detected, to be able to identify where in the hierarchy of components the fault occurred.
In response to these issues, design methodologies referred to as Design for Test (DFT) have been developed to allow much of the test development process to be automated. A commonly used DFT approach is internal scan test. It relies on the addition of specialized test circuitry to the IC. In contrast to functional test, which exercises the device as a whole using its normal operating mode, scan test uses the test circuitry in a separate scan mode to set or examine the state of the IC (or part of the IC), thus bypassing the intractable task of performing these operations using the normal operating mode. Since the device state is accessible, scan tests can exercise circuitry locally. This allows tests to be generated automatically, and allows the automated isolation of faults detected by the tests.
How Scan Test Works
The test circuitry added to the IC for scan test modifies the internal nodes of the device that retain state information from one cycle to the next, allowing these Scan Cell nodes to be linked together in a Scan Chain with its ends linked to a Scan Input and Scan Output pin. In scan mode, the Scan Chain functions as a shift register, allowing data values to be scanned into the scan cells at one end and out the other, one per cycle. The scan circuitry adds 10-15% to the circuitry of the IC. A typical configuration splits the scan cells among multiple scan chains. A greater number of chains reduces the number of cycles required to load and unload the IC state, but each chain requires connections to two pins. Depending on how this tradeoff is weighed, a typical configuration may contain 16-256 scan chains, with 200-2,000 scan cells per chain. The Scan Input and Scan Output normally share pins that serve a different purpose during normal device operation.
Conceptually, a scan test consists of a load phase, in which the scan chains are shifted multiple cycles in scan mode to set the state of the DUT, an exercise phase, consisting of one or more cycles in normal operational mode, and an unload phase, in which the scan chains are again shifted multiple cycles in scan mode to examine the state resulting from the exercise phase. An Automated Test Pattern Generation (ATPG) tool is used to automatically generate scan tests. A large number of scan tests are required to achieve high levels of fault coverage—a typical scan test program consists of 1,000-10,000 tests. Unlike traditional functional tests, scan tests have a highly consistent organization imposed by the ATPG tool, and, because each test resets the DUT state, there are no interdependencies between tests.
In practice, the size and execution time of a scan test program can be cut roughly in half by the simple optimization of overlaying the load and unload phases of successive tests. Each shift cycle unloads a result value for the completed test and at the same time loads a setup value for the next test.
In contrast to the cyclized form traditional test systems use to represent test programs, ATPG tools use a procedural representation of the test steps and a structured representation of the data values applied during the test. Data values may be represented as a parallel vector, a set of values to be applied to specified pins during a single cycle, or as a serial vector, a series of values to be applied to a scan chain across multiple cycles. Typically, the characteristic sequence of cycles required to perform the scan load/unload phase is specified as a separate procedure that is then invoked by individual tests with appropriate data values. A traditional tool for a test system translates this ATPG format into the tester's cyclized internal form.
Mismatch between Traditional Testers and Scan Test
The cyclized representation of test programs used by traditional test systems is not an effective representation for scan tests, for a variety of reasons.
A great deal of information is lost in the translation from the ATPG representation. Device specifications, in particular the structure of scan chains is lost. In scan tests, most test cycles are scan load/unload, not exercise cycles. This distinction is lost in the cyclized representation. Nor, typically, does it preserve the location of test boundaries.
The translation process typically involves tester-specific adjustments to the test program, so that the resulting program is slightly different from the original ATPG definition. In particular, signal timing and levels may be adjusted to meet tester constraints. These changes are not apparent in the resulting representation.
In traditional functional test, test data is associated with pins, but most of the data in scan tests is associated with scan cells internal to the IC. The association of this scan data with pins is merely an artifact of the scan load/unload mechanism. It is extremely difficult to determine which data values in the cyclized representation are scan data, much less the scan cells to which they correspond. (In summary, it requires locating the bounds of the load/unload cycles, identifying the scan input and scan output pins, and matching position of the value in the chain to a scan cell—a tedious and error-prone manual process.) Even determining which test a data values belongs to is not easy, and is complicated by the overlap between tests.
For traditional functional test programs, tests do not overlap. Tests can be executed selectively (if not compromised by interdependencies) by specifying a starting and ending cycle. The overlapping load/unload phases of scan tests interfere with this approach, and the traditional tester cannot perform the more complex split required to isolate scan tests for selective execution.
The problems caused by this mismatch are most apparent when an engineer has to diagnose failures in the test program. In particular, issues that can occur in the setup of the ATPG and in the translation of the scan patterns to the tester format often result in incorrect scan tests that the engineer must be debug. Typical scan test programs are enormous, and because of the mismatch, the traditional test system presents this data to the engineer in cyclized form—as a huge array of numbers—missing almost all the structural information that was present in the ATPG representation.